Add char?

Sure, I will add it.

I missed that one since the Utf8Formatter does not have a signature for it but the JsonSerializer supports it just fine.

What do you think about adding byte[] to this list?

@am11 We can support it and do as we do for a byte[] value, which is write/read it as a Base64 string.

For floating point (Single and Double) does GetHashCode() and Equals() work as expected? Since a given Single value may be 1.23 for example but can be represented in more than one binary representation (i.e. the 4 bytes may be different). By default Equals() compare bytes which wouldn't work correctly in all cases @tannergooding

For float/double (and IEEE binary floating-point numbers in general), every bit representation for finite or infinite, non-zero floating-point values represents something unique.

The exceptions are:

• +0.0 and -0.0
• The many representations of NaN

Both ==/!= and Equals then perform standard equality comparisons for all other values (all non-zero finite values, and +/-infinity).
For ==/!= and Equals, +0 == -0

For ==/!=, any comparison where one operand is NaN returns false
For Equals, NaN is equal to any other NaN, regardless of underlying bit representation.

GetHashCode follows the same rule as Equals. That is +0 and -0 return the same hash code. All NaN return the same hash code.

OK thanks. So using Single\Double as a dictionary key makes sense. After looking at the binary representation for the non-exception cases I see the exponent is always normalized by selecting the smallest value that produces the representation (so binary representation of 1.23 == 123e-2 for example).

Should it? Does Newtonsoft have this behavior?

Somewhat yes, Newtonsoft does not have a DictionaryKeyPolicy per se, but it definitely calls the DictionaryKeyResolver after the key is converted to string.

https://dotnetfiddle.net/A3uJ0H

It really doesn't matter, when the markdown renders, it automatically enumerates the list.
See the rendered doc.

Do you imagine the work to make the type public should be scoped for 5.0? This initial support doesn't provide a way for users to customize (de)serialization of non-string dictionary keys. Is this acceptable for most users?

As far as I have seen while writing the code, it does perfect sense to expose these types at some point, maybe you can make fit the effort needed for that into the 5.0 JSON roadmap.

I think we should avoid scope creep and keep extension point + making it public out of the feature for now.

Is this acceptable for most users?

That should be the goal by the default/built-in behavior. Let's say 80% folks are successful with it.

Add some more detail around using string property names?

• Use JSON property names for the key values. This produces more readable and smaller JSON and is consistent with Newtonsoft.Json.
  • However since property names must be a string, adds complexity since we now need a different mechanism to produce strings from non-string types.

I suppose an alternative is to not use string property names and instead use Name\Value combinations. Name\Value would likely be faster an just a few lines of code to enable since we don't need to add any new converter support.